Increasingly, people are obtaining services of one form or another over networks. For example, users of client devices may obtain news, television, weather information, and even a college education over a network from remotely-located computer services. Such client devices may take many forms, including but not limited to cell phones, personal digital assistants, laptops and desktop computers.
For a variety of reasons, it is useful to know how users are interacting with such remotely-provided services. For example, a service provider may find it useful to know that users frequently hover their input focus (such as a mouse pointer) over a certain portion of the display, or that users rarely use certain controls provided by the services. Service providers may collect data reflecting user interactions with remotely-provided services for the additional purposes of user personalization of the services, user profiling, system usage metrics, and other research purposes.
Remotely-provided services typically involve both client-side logic and server-side logic. The client-side logic of a service is typically responsible for generating a user interface through which a user may interact with the service. The server-side logic of a service is typically responsible for the content of the service, and for providing that content to the client.
Obtaining information about how users interact with services that are accessed using computing devices is referred to as “user tracking”. The modifications that are made to perform user tracking are referred to as “instrumentation”. Today most user tracking and web application instrumentation is performed either using cookies or by sending information about user actions and application performance immediately from the client-side to the server-side using “beacons”. These mechanisms are highly restrictive and limit the amount of information that can be collected on the client-side in a reliable manner and without unduly degrading the user experience.
For example, the information captured by cookies and beacons is typically limited to the user's “clickstream”. A clickstream indicates the controls, within the HTML pages provided by a service, on which the user has “clicked”. However, a user's clickstream conveys only part of the user's interaction with a web service. For example, a clickstream may not indicate when and where users move their input focus while interacting with the service. As another example, a clickstream may not be able to indicate how a user made a particular selection. For example, some web pages may provide a number of alternative input mechanisms (e.g. a clickable button, menu option, and a keyboard shortcut) to accomplish the same operation (e.g. saving a document in the application). The clickstream may indicate that the user selected the operation, but not which of the input mechanisms was used to initiate the operation. As another example, a clickstream may not indicate user interactions that are handled by client-side code, such as JAVASCRIPT™ or FLASH®, that is embedded in a web page delivered to clients by the service. It may be just as important to know how a user interacts with the interfaces generated by client-side code as it is to know a user's clickstream.
Unfortunately, capturing more than a clickstream presents several technical challenges. For example, the communication bandwidth from the client-side logic to the server-side logic (the “upstream bandwidth”) is often significantly lower than the communication bandwidth from the server-side logic to the client-side logic (the “downstream bandwidth”). Consequently, sending to the server-side detailed information about what a user is doing on the client-side may consume an unacceptably large amount of the relatively small upstream bandwidth.
In addition, Web application development has changed and more of the logic and user interface is now created or fully controlled on the client computer. Previously, the server would create the user interface elements and/or get a request for most, if not all, user actions via a post back (page reload). User tracking in these instances is accomplished by monitoring the user's clickstream generated by the user requests to the server as the user navigates the available resources. As “Web 2.0” technologies have proliferated, these mechanisms to track user actions are no longer sufficient to capture the variety of ways users interact with “Web 2.0” interfaces. Current solutions attempt to either immediately send all instrumentation data at the time it is gathered, or to queue information about a user's interaction with a page and then flush the queue by sending the information to the server-side when the page unloads. Unfortunately, sending the contents of a client-side queue to the server-side in response to the unloading of a page is not reliable, nor does it provide a good user experience when it is possible. Additionally, because current solutions keep user tracking data in volatile memory, the failed transmission of client-side queue data could result in the permanent loss of valuable user tracking data after a session is ended.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.